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The past several decades have seen the rise 
of large, highly interactive systems that are 
on the forward edge of technology. As a re- 
sult of this growth and the increased usage of 
digital systems (computers and software), 
the concept of systems engineering has 
gained increasing attention. Some of this at- 
tention is no doubt due to large program fail- 
ures which possibly could have been avoided, 
or at least mitigated, through the use of sys- 
tems engineering principles. The complexity 
of modern day weapon systems requires con- 
scious application of systems engineering 
concepts to ensure producible, operable and 
supportable systems that satisfy mission 
requirements. 

Although many authors have traced the 
roots of systems engineering to earlier dates, 
the initial formalization of the systems engi- 
neering process for military development 
began to surface in the mid-1950s on the bal- 
listic missile programs. These early ballistic 
missile development programs marked the 
emergence of engineering discipline “special- 
ists” which has since continued to grow. 
Each of these specialties not only has a need 
to take data from the overall development 
process, but also to supply data, in the form 
of requirements and analysis results, to the 
process. 

A number of technical instructions, mili- 
tary standards and specifications, and man- 
uals were developed as a result of these 
development programs. In particular, MIL- 
STD-499 was issued in 1969 to assist both 
government and contractor personnel in 
defining the systems engineering effort in 
support of defense acquisition programs. 
This standard was updated to MIL-STD- 
499 A in 1974, and formed the foundation for 
current application of systems engineering 
principles to military development pro- 
grams. 


In its simplest terms, systems engineer- 
ing is both a technical process and a manage- 
ment process. To successfully complete the 
development of a system, both aspects must 
be applied throughout the system life cycle. 
From a government’s program management 
point of view, the Defense Systems Manage- 
ment College favors the management ap- 
proach and defines systems engineering as 
follows: 

Systems engineering is the manage- 
ment function which controls the total 
system development effort for the pur- 
pose of achieving an optimum balance 
of all system elements. It is a process 
which transforms an operational need 
into a description of system parameters 
and integrates those parameters to op- 
timize the overall system effectiveness. 

A system life cycle begins with the user’s 
needs, expressed as constraints, and the 
capability requirements needed to satisfy 
mission objectives. Systems engineering is 
essential in the earliest planning period, in 
conceiving the system concept and defining 
system requirements. 

As the detailed design is being done, sys- 
tems engineers: 1) assure balanced influence 
of all required design specialties, 2) resolve 
interface problems, 3) conduct design re- 
views, 4) perform trade-off analyses, and 
5) assist in verifying system performance. 

During the production phase, systems en- 
gineering is concerned with: 1) verifying sys- 
tem capability, 2) maintaining the system 
baseline, and 3) forming an analytical 
framework for producibility analysis. 

During the operation and support (O/S) 
phase, systems engineering: 1) evaluates 
proposed changes to the systems, 2) estab- 
lishes their effectiveness, and 3) facilitates 
the effective incorporation of changes, modi- 
fications and updates. 
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Iterative Trade-Offs 



Figure 1 The Systems Engineering Process 


The Systems Engineering Process 

Although programs differ in underlying 
requirements, there is a consistent, logical 
process for best accomplishing system design 
tasks. Figure 1 illustrates the activities of 
the basic systems engineering process. 

The systems engineering process is itera- 
tively applied. It consists primarily of four 
activities: functional analysis, synthesis, 
evaluation and decision, and a description of 
systems elements. The product element 
descriptions become more detailed with each 
application and support the subsequent 
systems engineering design cycle. The final 
product is production-ready documentation 
of all system elements. 

Since the requirement to implement a 
systems engineering process may cause 
major budgetary commitments and impact 
upfront development schedules, it is impor- 
tant to understand the inherent objectives: 

• Ensure that system definition and design 
reflect requirements for all system ele- 
ments: equipment, software, personnel, 
facilities and data. 

• Integrate technical efforts of the design 
team specialists to produce an optimally 
balanced design. 

• Provide a comprehensive indentured 
framework of system requirements for 


use as performance, design, interface, 
support, production and test criteria. 

• Provide source data for development of 
technical plans and contract work state- 
ments. 

• Provide a systems framework for logistic 
analysis, integrated logistic support 
(ILS), trade studies and logistic documen- 
tation. 

• Provide a systems framework for produc- 
tion engineering anal ysi s, producibility 
trade studies, and production and manu- 
facturing documentation. 

• Ensure that life cycle cost considerations 
and requirements are fully considered in 
all phases of the design process. 

Successful application of systems engi- 
neering requires mutual understanding and 
support between the military and contractor 
program managers. They must be willing to 
make the systems engineering process the 
backbone of the overall development 
program. They must understand the need to 
define and communicate among the 
engineering specialty programs. They must 
recognize the role of formal technical reviews 
and audits, including the value, objectives 
and uniqueness of each formal review and 
audit. They must also know the objectives of 
the program and possess a thorough inter- 
pretation of the user’s requirements. 
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The output of the systems engineering 
process is documentation. This is the means 
by which it controls the evolutionary devel- 
opment of the system. Systems engineering 
prepares a number of technical management 
and engineering specialty plans that define 
how each phase of the acquisition cycle will 
be conducted. Draft plans are usually sub- 
mitted with the proposal and final plans are 
delivered in accordance with the Contract 
Data Requirements List (CDRL). These 
plans are used by the government to ensure 
compliance with the contract and used by the 
contractor to develop detailed schedules and 
allocation of resources. Specifications are 
submitted that form the basis for the design 
and development effort. Top-level specifica- 
tions are incorporated into the statement of 
work (SOW) and provided to the developer. 
The developer will allocate these top-level 
requirements to lower level system compo- 
nents (hardware and software) and submit 
the associated specifications and design doc- 
uments to the government for approval. The 
status of system development progress is 
tracked and documented in the form of tech- 
nical review data packages, technical perfor- 
mance measurement (TPM) reports, analysis 
and simulation reports and other technical 
documentation pertinent to the program. In 
summary, this documentation may include: 

• Systems Engineering Management Plan 
(SEMP) 

• Specifications (system, segment, develop- 
ment, product, process, material) 

• Design Documentation 

• Interface Control Documents (ICDs) 

• Risk Analysis Management Plan 

• Survivability /Vulnerability (S/V) Hard- 
ness Plan 

• Mission Analysis Report 

• Reliability Plan 

• Maintainability Plan 

• Integrated Logistics Support Plan (ILSP) 

• Software Development Plan (SDP) 

• Test and Evaluation Master Plan 
(TEMP) 


Producibility Plan 

Functional Flow Block Diagrams (FFBD) 
Requirements Allocation Sheets (RAS) 
Audit Reports 
EMI/EMC Control Plan 
Human Engineering Plan 
Trade Study Reports 

The systems engineering process is an 
iterative process applied throughout the ac- 
quisition life cycle. The process itself leads to 
a well defined, completely documented and 
optimally balanced system. It does not pro- 
duce the actual system itself, but rather, it 
produces the complete set of documentation, 
tailored to the needs of a specific program, 
which fully describes the system to be devel- 
oped and produced. Each program’s systems 
engineering process, developed through 
tailoring and/or adding supplemental re- 
quirements, must meet certain general crite- 
ria. Although not complete, the following 
guidelines should be considered in approach- 
ing the basic process: 

• System and subsystem (configuration 
item) requirements shall be consistent, 
correlatable, and traceable both within 
data produced as basic documentation 
(e.g., Functional Flow Block Diagram, 
Requirements Allocation Sheet, and 
Time Line Sheet) and as related docu- 
mentation (e.g., work breakdown struc- 
ture and Logistic Support Analysis 
Record). 

• The concept of minimum documentation 
shall be evident. 

• Acquisition and ownership cost shall be 
an integral part of the evaluation and de- 
cision process. 

• Baselines shall be established progres- 
sively as an integral part of the systems 
engineering process. 

• The systems engineering process shall 
result in a design that is complete, at a 
given level of detail, from a total system 
element viewpoint. 
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• The process shall provide for the timely 
and appropriate integration of main- 
stream engineering with engineering 
specialties such as reliability, maintain- 
ability, human factors engineering, 
safety, integrated logistic support, envi- 
ronmental assessments and producibility 
to ensure their influence on system 
design. 

• The process shall provide for continuing 
prediction and demonstration of the an- 
ticipated or actual achievement of the 
primary technical objectives of the sys- 
tem. Problems and risk areas shall be 
identified in a timely manner. 

• Formal technical reviews and audits 
shall be an integral part of the systems 
engineering process. 

• The systems engineering process shall be 
responsive to change. The impact of 
changes to system and/or program re- 
quirements must be traceable to the low- 
est level of related documentation in a 
timely manner. 


• Significant engineering decisions shall be 
traceable to the systems engineering ac- 
tivities and associated documentation 
upon which they were based. 

Figure 2 is an overview of the four basic 
steps of the systems engineering process. 

Functional Analysis 

Every engineering effort must begin with a 
statement of a perceived need. At the 
beginning of a DOD acquisition effort, this 
statement will be in the form of a system 
requirement document, usually developed 
through a Mission Area Analysis of antici- 
pated threats. 

Once the purpose of the system is known, 
the functional analysis activity identifies 
what essential functions the system must 
perform. In order to accomplish this, func- 
tional analysis is composed of two primary 
process segments: functional identification 
and requirements identification and 


Input Requirements 


• Mission Objectives 

• Mission Environments 

• Mission Constraints 

• Measurements of 
Effectiveness 



Technology Selection Factors 


Hardware 

Software 

Reliability 

Maintainability 

Personnel/Human Factors 

Survivability 

Security 

Safety 

Standardization 
Integrated Logistic Support 

System Mass Properties 
Producibility 
Transportability 
Electronic Warfare 
Computer Resources 



Description of System Elements 


• Equipment 

• Personnel 

• Facilities 

• Computer Software 

• Technical Data 


Figure 2 The Systems Engineering Process 
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allocation (functional performance require- 
ments analysis). It answers the “what” and 
“why” questions relative to system design. 

The basic analytical tool for functional 
identification is the Functional Flow Block 
Diagram (FFBD), showing logical sequences 
and relationships of operational and support 
functions at the system level. Specific func- 
tions will vary from system to system and 
will be traceable to mission requirements 
and objectives. Maintenance flow diagrams 
depicting general maintenance and support 
concepts will lead to analysis of require- 
ments on an end item/equipment basis. At 
this level, since functions are more standard- 
ized, functional identification is often accom- 
plished using the End Item Maintenance 
Sheet (EIMS) or Logistic Support Analysis 
Record (LSAR). Similarly, detailed test 
requirements are identified using the Test 
Requirements Sheet (TRS), and productivity 
requirements are identified using the 
Production Sheet (PS). 

It should be kept in mind that the sys- 
tems engineering process is always iterative. 
Each acquisition phase will involve function- 
al analysis to progressively more detail. For 
example, during the Concept Explora- 
tion/Definition (C/E) phase, analysis of 
support functions will concentrate on Main- 
tenance FFBDs, which will support the 
establishment of gross maintenance con- 
cepts. During Full Scale Development (FSD), 
emphasis will shift to detailed analysis of the 
maintenance requirements of specific equip- 
ment using the EIMS or LSAR. 

The Requirements Allocation Sheet 
(RAS) is used as the primary analytical tool 
for requirements identification and alloca- 
tion, or functional performance require- 
ments analysis as it often is referred to, in 
conjunction with FFBDs and special purpose 
documents such as EIMSs, TRSs, and PSs. 
The RAS serves three purposes in document- 
ing the systems engineering process: 1) ini- 
tially, it is used to record the performance 
requirements established for each function; 
2) during synthesis, it is used to show the 


allocation of the functional performance 
requirements to individual system elements 
or a combination of elements; and 3) follow- 
ing evaluation and decision, the RAS 
provides the functionally oriented data re- 
quired in the description of the system 
elements. 

The Time Line Sheet (TLS) is used to 
perform and record the analysis of time- 
critical functions and functional sequences 
In performing time requirements analysis 
for complex functional sequences, additional 
tools, such as mathematical models or 
computer simulations, may be needed. Time 
requirements analysis is performed in any or 
all of the functional cycles of the process to 
determine whether time is a critical factor. 
The TLS complements the FFBD in its 
ability to show a lower level of detail, as well 
as to illustrate the impact of concurrent 
functions within a given sequence. TLSs are 
used to support the development of design 
requirements for the operation, test and 
maintenance functions. They identify time- 
critical functions and depict the concurrency, 
overlap and sequential relationship of 
functions and related tasks. Time-critical 
functions are those that affect reaction time, 
downtime or availability. 

Synthesis 

Synthesis supplies the “how” answers to the 
“what” outputs of functional analysis. 

Two documentation tools accomplish and 
record the synthesis of design approaches or 
alternative approaches. The Concept 
Description Sheet (CDS) is used to collect the 
performance requirements and constraints, 
as delineated by functional analysis, that 
apply to an individual subsystem or end 
item. The CDS also describes at the gross 
level a design approach for meeting the 
requirements. The Schematic Block Dia- 
gram (SBD) is used to develop and portray 
the conceptual schematic arrangement of 
system elements to meet system and/or 
subsystem requirements. The CDS and SBD 
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are both applicable to all acquisition phases 
and provide the basis for development of the 
descriptions of system elements. 

Evaluation and Decision 

Since program risk and cost are dependent 
on practical trade-offs between stated oper- 
ating requirements and engineering design, 
continual evaluations and decisions must be 
made not only at the beginning of the 
program but throughout the design and 
development activity. 

The Trade Study Report (TSR) is used to 
summarize and correlate characteristics of 
alternative solutions to the requirements 


and constraints that establish the selection 
criteria for a specific trade study area. The 
report also documents the rationale used in 
the decision process and should present risk 
assessment and risk avoidance consider- 
ations. Other tools, such as analytical or 
mathematical models or computer simula- 
tions, may be needed and used in accomplish- 
ing the evaluation and decision process. 

Description of System Elements 

All systems can be defined by a set of inter- 
acting system elements which fall into five 
categories: equipment (hardware), software, 
facilities, personnel, and procedural data. 
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Description of 
System 
Elements 


Basic 

Documen- 

tation 


Identify and se- 
quence functions 
tnat must be accom- 
plished to achieve 
system or project ob- 
jectives. Develop the 
basis for establish- 
ing intersystem 
functional interfaces 
and identify system 
relationships. 


Requirements 
Allocation Sheets 
(RAS) 

Define the require- 
ments and constraints 
for each of the func- 
tions and relate each 
requirement to the sys- 
tem elements of 

a. Equipment 

b. Facilities 

c. Personnel 

d. Procedural data 

e. Computer software 

Time Line Sheets 
<TLS) 

Present critical func- 
tions against a time 
base in the required se- 
quence of accomplish- 
ment. 
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Concept 

Description Sheets 
(CDS) 

Constrain the de- 
signer to stop at a 
point in the cycle and 
create at the gross 
level a design or syn- 
thesis meeting the 
FFBD, RAS, TLS 
requirements and 
constraints. 

Schematic 
Block Diagrams 
(SBD) 

Develop and portray 
schematic arrange- 
ment of system ele- 
ments to satisfy sys- 
tem requirements. 


Trade 

Study Reports 
(TSR) 

Select, evaluate and 
optimize promising 
or attractive con- 
cepts. Document the 
trade-off and sup- 
porting rationale. 
Consider all possible 
solutions within the 
framework of re- 
quirements. 


Design 

Sheets 

IDS) 

Define, describe and 
specify performance, 
design and test cri- 
teria for the system 
elements 

a. Equipment 

b. Facilities 

c. Personnel 

d. Procedural data 

e. Computer soft- 
ware 


Special 

Purpose 

Documen- 

tation 


End Item 

Maintenance Sheet 
(EIMSVTest Reqmt 
Sheet (TRS)/ 
Production Sheets 
(PS)/Logistic Sup- 
port Analysis 
Record (LSAR) 
Identify mainten- 
ance, test and pro- 
duction functions on 
a specific end item, 
subassembly, and 
component basis. 


Facility Interface 
Sheets 
(FIS) 

Identify environ- 
mental and physical 
interfaces between 
equipment and fa- 
cilities on an end 
item basis. 


Indenture is carried to the level required for the selected level of engineering to identify, describe and specify. 

Figure 3 Basic and Special Purpose Documentation for Systems Engineering 
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Two documentation forms are used to 
describe these system elements: the Design 
Sheet (DS) and the Facility Interface Sheet 
(FIS). The DS is used to establish and 
describe the performance, design and test 
requirements for equipment end items, criti- 
cal components and computer software 
programs. The FIS is used to identify the 
environmental requirements and interface 
design requirements imposed upon facilities 
by the functional and design characteristics 
of equipment end items. The DS and FIS 
provide the basis for the formal identifica- 
tion required for configuration management. 

The systems engineering process pro- 
duces the basic and special purpose docu- 
mentation that controls the evolutionary 
development of the system. Figure 3 
correlates the particular documentation 
associated with each step of the systems 
engineering process. 

The systems engineering process itself 
does not actually produce the system, but 
produces the documentation necessary to de- 
fine, design, develop and test the system. As 
such, a variety of engineering and planning 
documentation is required throughout the 
acquisition cycle, and systems engineering is 
the vehicle used to produce that documenta- 
tion. 

Numerous plans are prepared to define 
which technical activities will be conducted. 
They address the integration of engineering 
specialties requirements, “design-for” re- 
quirements and organizational resource 
requirements, and discuss how progress 
toward system-level goals will be measured. 
The Systems Engineering Management Plan 
is the key planning document that reflects 
these requirements. Contractor compliance 
with these plans is monitored by government 
organizations to ensure that standard poli- 
cies and procedures in the area of systems 
engineering are employed. Additionally, 


specifications are prepared as part of the- 
systems engineering process to form the 
basis for the design and development effort. 
The top-level specification (system or seg- 
ment) is normally approved and draft lower 
level specifications (configuration items) are 
developed reflecting allocated system re- 
quirements to lower level components or sub- 
systems, which designers and subcontractors 
translate into hardware and software pro- 
duction plans. 

In order to provide a continuing assess- 
ment of the system’s capability to meet 
performance requirements, the systems 
engineering organization prepares technical 
review data packages, technical performance 
measurement (TPM) reports, analysis and 
simulation reports, and other documenta- 
tion. 

The systems engineering process is one 
approach to providing disciplined engineer- 
ing during all acquisition phases. Although 
current application of the process has focused 
on C/E, D/V, and FSD, systems engineering 
process techniques and principles are equal- 
ly applicable to the analysis and definition of 
production requirements. 

The systems engineering process also pro- 
vides the logic and timing for a disciplined 
approach, with certain internal assurances 
of technical integrity such as traceability. 
Technical integrity ensures that the design 
requirements for the system elements reflect 
the functional performance requirements, 
that all functional performance require- 
ments are satisfied by the combined system 
elements, and that such requirements are 
optimized with respect to system perfor- 
mance requirements and constraints. 

The DSMC Systems Engineering Man- 
agement Guide may be purchased from the 
U.S. Government Printing Office (1991-306- 
417 -QL 3). 



